1. Field of the Invention
The present invention relates to an electronic signature delegation method whereby a delegate can execute an electronic signature on predetermined data in his terminal in the name of at least one titleholder who has mandated the delegate.
2. Description of the Prior Art
An electronic signature guarantees the authenticity of a document, i.e. securely authenticates one or more signatories having executed the signature, and guarantees that the document has not been tampered with. The electronic signature is often used to guarantee non-repudiation of the document, i.e. to guard against denial of the document by its author.
The formats most routinely used for signed messages are the standardized PKCS#7, CMS, XML-DSig and PGP formats.
Known electronic signature formats offer no means for including an annotation of signature delegation. The use of multi-agent cryptography, which assures the anonymity of a signatory belonging to a group of agents by signing in the name of the group, allows the inclusion of sufficient information for managing signature delegation in a pre-specified context of signature validity.
Some of the signature formats previously cited enable integration of a plurality of signatures into a single file. On the other hand, they are not adapted to collect signatures issued by a group.
At present, few electronic signature systems provide for signature delegation.
Where signature delegation does exist in an electronic signature system, it generally relates to delegation of rights, with means for managing authorizations effected internally by the system, in the most favorable cases via a more general directory.
For example, a group of “titleholders” who have the right to take decisions within the system can be defined in a workflow. To alleviate titleholder absences, one or more “delegates” can be attached to each of the titleholders.
A titleholder can decide, for example at the time of an action in the workflow such as a declaration of paid leave, to assign some or all of the titleholder's authorizations to the delegate for a predetermined delegation period in order not to cause discontinuity in the workflow. Decisions in the workflow taken by the delegate are taken in the name of the titleholder.
All trace of the delegation is usually lost when the delegation period ends. In the most favorable situations, the delegation can be uncovered from workflow logs, but this requires a complex and costly search operation, especially if the search is conducted a long time afterwards.
In the case of workflows including an electronic signature, in which case the object of the decision is the electronic signing of a document, existing electronic signature formats do not provide a “signed on behalf of” field identifying the titleholder in whose name the signature has been effected by the delegate. The signed document, once it has left the workflow, for example for processing by a third party or archival storage, includes only the signature of the delegate, with no trace of the person in whose name the delegate effected the signature.
Because the delegation of power is not included in the electronic signature, it cannot be uncovered once the signed document has left its delegation context.
Now, the electronic signature must be durable, and the elements for determining the conditions under which the signature was executed must likewise remain durable, for example by adding the written annotation “per pro” in the case of a manuscript signature.
Furthermore, delegation often necessitates, for the titleholder and/or the delegate, intervention by the management means for authorizing delegation.
To show that a manuscript signature is effected on behalf of someone else, the manual signature on the signed document is followed by a handwritten annotation of the “per pro” type. This method can be reproduced identically in an electronically signed document if a field to accommodate this kind of annotation is provided in the format of the document to be signed.
Unfortunately, there is no such field, and adding within the format of the document it is difficult. Semantic analysis of the content of the document is necessary to recover information relating only to the signature.
It will be noted that it is very often the case, in forms or in workflows, that an electronic signature does not apply to the document, such as a formatted text, but rather to a set of data concatenated into a string of characters belonging to the electronic document and which may or may not be displayable.
The conventional electronic signature as described above transposes the manuscript signature mechanism into the electronic domain. Another form of electronic signature, based on multi-agent cryptography techniques, offers not only features that are close to the basic signature, such as some degree of guarantee as to the source of a message, but also features that are radically different, such as the anonymity of the signatory within a group of persons. Three techniques are described hereinafter:                the group-signature technique, in which the signature is effected by a member of a group administered by an authority;        the set-signature technique, in which the signature is effected by a person in the name of a set of persons without them being part of an administered group; and        the trivial multi-agent signature technique, in which information on other agents that it is required to include in the signature process is added.        
The group-signature technique involves at least one signatory, a group of members to which the signatory belongs, and an authority. A member of the group signs in the name of the group, but anonymously. When an entity validates a group signature, it is certain that the signature has been effected by one of the members of the group, without being able to tell which one. Only one entity is authorized to determine the identity of the signatory, namely the authority. In this case, it is said that the authority “opens” the signature and that the group signature is of “limited anonymity”. The anonymity can be beneficially lifted, in particular in the event of fraud or to ensure the correct operation of a service, for example bidding.
As a general rule, the group-signature technique necessitates an initialization phase and uses specific cryptographic keys.
Furthermore, the group-signature technique requires the group administrator to manage the group using complex operations for adding a new member to the group and removing a member from the group.
The set-signature technique differs from the group-signature technique in that:                the persons of the set in whose names the signatory applies his set signature do not belong to a group, i.e. are not registered as forming part of a group, and thus have not given their explicit consent;        there is no authority; and        unless the signatory is explicitly mentioned, anonymity cannot be lifted.        
It is nevertheless assumed that all potential signatories have public keys accessible to the signatory. No configuration phase is needed. As there is no authority, the set signature offers complete anonymity, i.e. nobody can ever determine who is the actual signatory.
The set-signature technique has three main drawbacks. The first is its irrevocable anonymity, which is sometimes a highly undesirable property. The second is the presumed slowness, and therefore data processing cost, of signature and verification, especially when the number of persons in the set is high. The third is recovering the certificates of all the persons of the set.
The trivial multi-agent signature method relies on a fundamental object establishing confidence in a public key associated with a private key for a titleholder or delegate user. The object referred to is an electronic certificate issued by a certification authority. It includes in particular the public key to be certified, the identity of the holder of the public key, a certificate validity period, a list of key usage attributes corresponding to rights of use of the key, supporting parameters such as a message signature key or a secure web server key, for example, and a cryptographic signature of the above data contained in the certificate and generated using a private key of the certification authority that issued the certificate. Confidence in the public key associated with a user identity relies on the validity of the certificate.
In the trivial multi-agent signature method, the signatory applies his signature to a document using the standard method and, in an additional field, adds, in addition to his own certificate, the certificates of the other agents that the signatory wishes to involve in the signature, and where applicable a field to be filled in with additional information. For example, in the case of delegation, the delegate includes his own certificate, the titleholder certificate, and a field indicating “per pro”.
The certificates added in this way are not necessary or useful for verifying the signature, and are present only for information. They can perfectly well be removed, or others can be added, without this modifying the signature. The format of the additional field is not standardized, even if it can be included in the form of a non-authenticated attribute.